Alibaba Cloud Japan Cn2 Faq Troubleshooting And Log Analysis Quick Start

question 1: how to quickly locate the delay and packet loss of alibaba cloud japan cn2 link?

common causes

when high latency or packet loss occurs, common causes include: uplink/downlink congestion, isp (operator) intermediate routing anomalies, instance network current limiting, cross-border egress restrictions, or local firewall policies. for alibaba cloud japan 's cn2 line, you need to pay attention to both the cloud and operator paths.

troubleshooting steps (quick commands)

- run on ecs: traceroute -n ip or mtr -c 100 ip (observe hop count and packet loss node).

- use ping -c 100 ip to detect the overall packet loss rate and delay jitter.

- check the instance network speed limit: ss -s / ifconfig / ethtool to view network card statistics; check the bandwidth package (if bandwidth package is used) and instance bandwidth configuration.

log and monitoring analysis

- view incoming and outgoing traffic, packet loss rate, and link errors (rx/tx errors) in cloudmonitor.

- retrieve access logs related to the target ip/time period in the log service to confirm the request endpoint and time window, such as filtering by client_ip, request_time in sls: query examples (pseudo-syntax) can be adjusted according to the query template generated by the api console.

question 2: if it is suspected to be a bgp/routing problem, how to troubleshoot routing abnormalities on alibaba cloud japan cn2 ?

common causes

bgp route instability or path changes caused by carrier-side policies, community filtering, black holes, or incorrect as route advertisements can cause access failures or traffic detours.

troubleshooting steps (quick commands)

- use traceroute/mtr to locate the hop where the exception started (usually you can see the asn/geographical information of the hop).

- check the vpc routing table, cen (if used), and cloud enterprise network policy in the alibaba cloud console to confirm whether the route has been overwritten.

- contact alibaba cloud after-sales service or the operator, provide the traceroute output and time point, and request confirmation of the bgp routing announcement and as path.

logging and analysis tips

- record the time point of each routing change in the operation and maintenance log (combined with cloudmonitor alarm time), and query relevant traffic mutation logs (such as syn retransmission, connection timeout) according to time windows in sls.

question 3: when the connection is reset or the handshake fails, how to troubleshoot the reasons on the application and network sides?

common causes

connection rst/handshake failure is usually caused by security group/acl denial, operating system level restrictions (such as conntrack, file descriptors), intermediate device (nginx, load balancing) misconfiguration, or peer policy.

troubleshooting steps (quick commands)

- use tcpdump to capture the three-way handshake packet: tcpdump -i eth0 host xxxx and port 443 -w capture.pcap; use wireshark/filters to analyze syn/syn-ack/rst.

- check the local port listening and connection status: ss -tunlp | grep target port; check conntrack: cat /proc/net/nf_conntrack or conntrack -l.

- check the security group and network acl: confirm that the inbound and outbound rules allow the destination port and source ip.

logging and analytics examples

- search for keywords such as 4xx/5xx and backend connection errors in load balancing/application access logs; perform aggregate statistics based on status_code and backend_error in sls to find the high-incidence time period.

question 4: how to use alibaba cloud log service (log service) for rapid log analysis and alarm location?

common causes

failure to report logs, incomplete indexes, or inaccurate query conditions will affect troubleshooting efficiency. proper configuration of log collection, indexing and alarm rules is key.

troubleshooting steps (quick commands/operations)

- confirm that ecs/slb/alb/application has correctly configured sls log collection (logtail or sdk), and check whether the logstore has recent data.

- use sql queries in the log service console for fast aggregation, such as grouping statistics by client_ip and status: select client_ip, count(1) as cnt from logstore where __time__ between xxx group by client_ip order by cnt desc.

- configure alarms: set trigger conditions based on query results (such as the number of 5xx failures exceeding the threshold within 5 minutes), and bind sms/dingtalk/email notifications.

practical points of log analysis

- use sliding window aggregation (for example, 1 minute, 5 minutes) to locate sudden problems; combine the request link (traceid) to correlate network anomalies with application logs for root cause analysis.

question 5: how to quickly confirm problems caused by security groups, operating system firewalls, or middleware throttling?

common causes

misconfigured security group rules, iptables/nftables interception, operating system sysctl parameters (such as net.ipv4.tcp_tw_reuse) or middleware (nginx, iptables-rate-limit) flow limiting can cause connection failures or performance degradation.

troubleshooting steps (quick commands)

- check the security group rules: check the inbound/outbound direction rules of the security group on the alibaba cloud console, especially the permission and priority of 0.0.0.0/0.

- check the firewall locally: iptables -l -n --line-numbers or nft list ruleset; check conntrack and sysctl: sysctl -a | grep net.ipv4.

- if you use load balancing, check whether the backend health check configuration and session persistence (sticky) policy cause connection abnormalities.

log and evidence collection

- collect /var/log/messages, application logs and tcpdump packet captures as evidence; create index fields (such as rules and actions) in sls to quickly locate requests rejected by the firewall.